ci(wasip2): document and test wasm32-wasip2 support (Postgres + MySQL)#4309
ci(wasip2): document and test wasm32-wasip2 support (Postgres + MySQL)#4309ricochet wants to merge 1 commit into
Conversation
SQLx already runs on wasm32-wasip2 with no library changes: the standard
`runtime-tokio` feature works there because Tokio's `net` driver builds on
WASI via mio. Pooling, LISTEN/NOTIFY, timeouts, and rustls TLS all work.
Building for the target requires `--cfg tokio_unstable` and a current-thread
runtime (WASI has no threads in wasip2 target).
This documents and exercises that support:
- README: add a WebAssembly (`wasm32-wasip2`) section covering the
`runtime-tokio` setup, the two target requirements, what works, and the
remaining limitations (hostname lookup needs `--allow-ip-name-lookup`,
native-tls is unavailable, MySQL caching_sha2 over plaintext needs
`mysql-rsa`).
- examples/wasip2/{postgres,mysql}: runnable pool examples that do a real
round-trip — create a table, insert rows in a transaction with bind
parameters, read them back ranked, and aggregate. A shared
`.cargo/config.toml` sets `--cfg tokio_unstable` so a plain
`cargo build --target wasm32-wasip2` works.
- CI: a `wasip2` job builds both examples and runs them under Wasmtime
against Postgres and MySQL service containers, asserting the query
output to catch wasm-specific decode regressions.
Signed-off-by: Bailey Hayes <bailey@cosmonic.com>
|
CI on main is failing. Created a PR to fix: #4311 |
|
As I mentioned in #4058 (comment) I don't really see the point in maintaining support for an unstable or tier 2 compilation target. I feel this even more strongly now, because there looks to be significant changes coming to I/O (and especially async I/O) in wasip3: https://wasi.dev/releases/wasi-p3#what-changed-in-each-interface This seems likely to be a moving target for a while yet, and I just don't have the bandwidth to spend time on issues related to this. |
|
Understood on maintainer resources and time. If there is ever renewed interest, I would gladly jump in as a codeowner for wasi support. wasip3 itself is stable and launched (wasip2 is also stable). I've also already tested sqlx with wasip3 and it does not require any changes to work. This is the end-user-friendly version of the WASI 0.3 release notes that I wrote. |
2 participants
SQLx already runs on wasm32-wasip2 with no library changes: the standard
runtime-tokiofeature works there because Tokio'snetdriver builds on WASI via mio. Pooling, LISTEN/NOTIFY, timeouts, and rustls TLS all work. Building for the target requires--cfg tokio_unstableand a current-thread runtime (WASI has no threads in wasip2 target).This exercises that support:
wasm32-wasip2) section covering theruntime-tokiosetup, the two target requirements, what works, and the remaining limitations (hostname lookup needs--allow-ip-name-lookup, native-tls is unavailable, MySQL caching_sha2 over plaintext needsmysql-rsa)..cargo/config.tomlsets--cfg tokio_unstableso a plaincargo build --target wasm32-wasip2works.wasip2job builds both examples and runs them under Wasmtime against Postgres and MySQL service containers, asserting the query output to catch wasm-specific decode regressions.